One or more aspects of the present invention relate to managing representational state transfer architecture resource collections within a computer system.
Networked computer systems offering a multitude of services to users are commonplace. Indeed, society is shifting towards an electronic way of life, in which many daily tasks are performed over such networks. For example, social interaction and commerce are performed over networks implementing services or applications (apps). Developers can create services or apps using an application programming interface (API) developed and supported by the service provider. The API for a service provider may implement a Representational State Transfer (REST) architecture that consists of clients and servers. Clients initiate requests to servers, which process requests and return appropriate responses to the clients. Requests and responses are built around the transfer of representations of resources. A resource can be virtually any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a resource. Generally, a RESTful architecture, i.e. an architecture which complies with the REST style, must be client-server based, stateless, cacheable, layered, use a uniform interface, and may provide code on demand. Similarly a RESTful resource is a resource which may be implemented or employed within a RESTful architecture, and a RESTful API is an API for a service implemented within a RESTful architecture.
The fundamental concept in any RESTful API is the resource. A resource is an object with a type, associated data, relationships to other resources, and a set of methods that operate on it. It is similar to an object instance in an object-oriented programming language, with one difference being that only a few standard methods are defined for the resource (corresponding to the standard HTTP GET, POST, PUT and DELETE methods), while an object instance typically has many methods. Therefore, a typical API may include a defined set of Hypertext Transfer Protocol (HTTP) request messages along with a definition of the structure of response messages. The definition of the structure of the response messages may for example be in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format.
Resources may be grouped into collections. Each collection should be homogeneous in that each collection should contain only one type of resource, and may typically be unordered. Collections are themselves resources. Collections may exist globally, at the top level of an API, but may also be contained inside a single resource. In the latter case, we refer to these collections as sub-collections. Sub-collections are usually used to express some kind of “contained in” relationship.
With the focus on API and Service Management in the Cloud, the management of RESTful resources and resource collections is increasingly important. Traditionally, there are two ways to serve up a collection of RESTful resources both of which are problematic especially with regards to evolving and changing resource and resource collections.
A first management approach has been to define a collection as an entirely ‘virtual’ resource. The contents of the collection are inferred by the server from the path segments of the requested Uniform Resource Identifier (URI). As ‘virtual’ collection resources tend to rely on the structure of the Resource URIs being completely fixed, changing the URI structure or adding additional collections is made very difficult.
A second management approach has been to define a ‘persisted’ collection resource. In such an approach, the ‘persisted’ collection may contain a list of references to the resources in the collection. When a new resource is added or removed, then the list in the collection resource must be updated at the same time.